The Session Initiation Protocol (“SIP”) is an Internet signaling protocol for establishing, managing, and terminating communication sessions, including instant messaging, Internet telephone calls, and Internet video conferencing. SIP is specified in Internet Engineering Task Force Request for Comments 2543 and Request for Comments 3261, which are each incorporated herein by reference. SIP sessions involve one or more participants or clients (typically a caller and a callee). The SIP messages are routed between each end-point SIP node (e.g., the caller and callee) through a network of SIP nodes, typically various servers.
There are generally two types of SIP messages: requests which are sent from the caller (e.g., endpoint SIP node) to the callee, and responses which are sent from the callee to the caller in reply to the request. In some cases, a callee may also send a request to the caller after the dialog session is initiated. Each SIP message, whether a response or a request, generally includes three parts: a start line, headers, and a body. The start line conveys the message type (e.g., request or response) and the protocol version, and the message body includes the content of the message and may convey session description information beyond the signaling information in the start line. The SIP header fields convey attributes of the message and modify the message meaning. Some attributes of the message stored in the header fields are instructions on how to route the message as well as document the actual route traveled by the message. For example, each SIP node which manages a request on its route will add a ‘VIA’ header containing information identifying that SIP node, such as a fully qualified domain name or Internet Protocol address. In this manner, loops in the routes may be detected and the response uses the VIA headers from the request to determine the route to be traveled to return to the caller. However, the particular path of a message may not be fixed over time, thus, the SIP node, such as a home server, may receive a first request of a dialog, such as a telephone call, but may not receive subsequent requests in the same dialog. To remain ‘in the loop’ for that dialog, the SIP node may insert a RECORD-ROUTE header containing information identifying itself, such as a uniform resource indicator (“URI”) or other address that allows other servers or endpoints to reach the SIP node. Portions of the completed list of RECORD-ROUTE headers are then copied by the receiving end client (callee for requests and caller for responses) into a set of ROUTE headers. The ROUTE SET headers contain data providing instructions to SIP nodes on how to route any future requests within the same dialog session.